Many organizations make information available in electronic form on websites. Such electronic distribution permits users to obtain the information whenever they need it, from wherever they happen to be. Users commonly access the resources with a software program known as a Web browser, or simply “browser.” The browser acts as the client in a client-server interaction; the server's role is usually performed by a second software program known as a Web server. The browser and Web server communicate according to a protocol known as the Hypertext Transfer Protocol (“HTTP”), which is described in Internet Engineering Task Force (“IETF”) Request For Comments (“RFC”) number 1945. Subsequent RFCs describe extensions and modifications to the protocol.
HTTP is a “connectionless” protocol. That is, despite its use of the connection-oriented Transmission Control Protocol (“TCP”), there is no inherent mechanism to permit the server to determine whether two requests came from the same client. A client establishes a connection and transmits a request for a document or other resource, which it identifies with a string known as a “Uniform Resource Locator” or “URL.” The server responds by transmitting the requested data (or an error or other indicator) to the client; after this request-response sequence, the TCP connection is closed. (Certain extensions to HTTP permit several transactions to occur over a single TCP connection for improved efficiency, but each request is essentially independent, and the protocol permits each transaction to occur separately.)
RFCs 2109 and 2965 describe HTTP State Management Mechanisms where a server can issue a parcel of data known as a “cookie” to a client. When the client makes subsequent requests to that server, it sends the cookie with the request, and the server can use the data in the cookie to correlate the present request with earlier requests by the same client. A client will only send the cookie to the server that set it (or, in some circumstances, to a server in the same domain).
HTTP also provides mechanisms for protecting certain materials on a Web server against public access. These mechanisms permit the operator of a Web site to restrict access to certain documents or other information. To obtain copies of restricted materials, a browser must present credentials that are acceptable to the server. Often, the credentials are a username and password that were entered by the browser's user. Each request to the Web server (or for a subset of the information on the server) is accompanied by the credentials. Like RFC-2109 cookies, user credentials are only transmitted to one server (the server that originally requested the credentials).
The request-correlation and state management made possible by HTTP cookies and the user authentication capabilities of the protocol are rudimentary, but adequate for many purposes. However, some organizations maintain many servers for performance, redundancy, or other reasons. These servers often operate under different domain names. In one typical network topology, client requests are directed to a hub, or “caching,” server, and then forwarded to one or another “origin” servers where the requested data actually reside. In another common topology, requests from a number of clients (for example, all of the users at a university or corporation) are sent to a proxy server, which forwards the requests to the servers where the requested data reside. Both of these topologies can interfere with HTTP state management and authentication and cause undesirable effects such as repeated demands for credentials from a user whose identity has already been sufficiently proven to at least one of the servers. Methods of coordinating Web server operations to relieve these undesirable effects may be useful in many situations.